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Previous writers in this series have attempted to 
show how the road to non-computing can be 
fostered at its foundations by: 

( 1 ) Engineering glitches into the hardware. With suit- 
able ingenuity, these can be either new botches (discov- 
ered after the prototype is constructed, usually, and then 
firmly cast in concrete) or loving repetitions of what never 
did work right. 

(2) Marketing the resulting Kludge with the same tech- 
niques used to peddle deodorants and cigarettes. The an- 
alogy is painfully accurate. 

(3) Applying time-tested rules for maintenance which 
operate faithfully to minimize uptime. These rules are a 
sort of check list for the Kludge Fixer so he can save time 
by listing excuses by the numbers. 

Now, brief reflection quickly reveals that the above ap- 
proaches are only the foundation. The real approach today 
has far greater scope, since it strikes at the heart of the 
matter — software. Everyone knows that software is the 
thing. The planners at Kludge Komputer Korporation are 
keenly aware of this trend. Having pioneered so well in 
the fundamentals, they can be expected to excel here too. 
What follows is the basic outline followed at KKK. The 
Master Plan is the result of years of study and represents 
the ultimate in software systems for users of the famous 
line of Kludge hardware. 

Kludge software master plan 

The cardinal Commandment of any software development 
program is "Announce it first, worry about producing it 
later." 

The first and most important Edict is, "Always start with 
fresh programmers." This is a simple rule and its raison 
d'etre is obvious. Any programmer who has used or de- 
signed another system has been adulterated or biased and 
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such bias (sometimes referred to as experience) may well 
influence him in the task he is to perform. 

Edict 2. "Never let your fresh programmers talk to the 
programmers who designed the last software package, if 
this can be avoided — but at all costs never let any soft- 
ware programmers talk to the people who design, sell or 
maintain the hardware." This rule needs no explanation. 

Edict 3. "Never let the software specifiers talk to the 
software implementers." This form of warping young pro- 
grammers' minds is to be avoided like the plague. Software 
designers always seem to have the weird idea that they 
better than anyone else, know how to implement their de- 
signs. 

Edict 4. "Never let a software group know that there 
are other groups." A weaker form of this rule is also useful, 
"Never let one software group know what the others are 
doing." The stronger form of this rule tends to create very 
high morale or esprit de corps brought about by a feeling 
of exclusiveness. In the weaker, but more pragmatic form, 
the effect is acquired by implanting the idea that all of the 
people in all of the other groups are a bunch of inexperi- 
enced poopheads. 

Edict 5. "If you must document the software, be sure 
that the documentation is done by a wholly separate group, 
preferably technical writers who are not too. knowledge- 
able about computers and programming." Many benefits 
accrue from this approach, but the greatest one is the high 
regard with which your documents will be copied. Worry 
not about their accuracy; users are more adaptable than 
you think. The proof of this is found in the great number 
of installations still operating Kludges with no documenta- 
tion. 

Turning our attention now to the design phase of soft- 
ware (predicated of course upon the above personal prac- 
tices) the following rules have served not only the Kludge 
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komputer Korporation I>i it many of its fellow companies 
for many years. 

Rule I. "Every software package must have a monitor, 
irrespective of the size of the Kludge." Without a monitor 
to occupy between 25 and 50? of the available fast store 
(and at least )k of the backup storage) the users' program- 
mers will become careless. They will eventually discover 
that one can trade time for space — which leads to re- 
duced utilization and thus, rental income. An appropri- 
ately designed monitor on the other hand can be depended 
upon to waste a minimum of 10? of the available time just 
searching the system tapes. 

Rule 2. "All error messages must be as coy and ambigu- 
ous as possible." The object here is to make the console 
operator (and, later, the programmer) unstable. For ex- 
ample, what could be simpler than "AN IMPOSSIBLE 
ERROR HAS OCCURRED ON AN UNSPECIFIED 
UNIT WHILE EXECUTING AN UNIDENTIFIABLE 
PROGRAM." It should be pointed out that the creative 
souls who can compose such wonderful phrases are rare 
beasts, indeed, and when found should be coveted and 
nurtured. 

Rule 3. "There should be more phases in the monitor 
than there are jobs or programmers in a given shop." This 
is the only realistic settlement to the ever raging argument 
between the one-phase and three-phase proponents. Be- 
sides, how else can you provide the capability for clobber- 
ing programmer A's phase p results while running pro- 
grammer B's phase q interlude if everyone knows what is 
to happen in each phase? And what better way to keep an 
operator guessing — you see he is much less likely to call 
for the KF's under these circumstances — another form of 
saving not to be discounted. 

Rule 4. "Every software routine should have a snappy 
acronymic name." For instance, we at Kludge Korpora- 
tion called our Kludge Monitor System KLUMSY; the 
Kludge assembler, KLAP; and the alternate version, KLAP- 
TRAP, required for a Kludge with traps (working or not) . 
Rule 5. "Before letting pragmatic aspects interfere, be 
sure that the things that count are taken care of. SEE 
THE SALES DEPARTMENT FIRST AND THE COPY 
WRITERS IMMEDIATELY." As we all know, if a Kludge 
can't be sold on its hardware merits alone, (and it can't) 
the software must carry the burden. 

A Kludge cannot subsist on a monitor alone. Thus it be- 
hooves the Kludge software suppliers to provide working 
languages for the Kludge. The more the merrier. Since 
the list of OK languages changes from season to season, 
and position within the list is not constant (or comput- 
able), one had best consult one's marketing people to 
find out which ones have strongest current motivational 
appeal. Within these bounds, the guiding principles of 
Kludge languages follow. 

Principle 1. "Hop aboard all of the current band wag- 
ons." If FORTRAN is the current best selling gee-wiz, 
write (promise) a better one. Change the name slightly so 
that you don't lose your identity, but not so much so that 
you can't tell who whelped it. Thus, Kludge Korporation's 
version of FORTRAN will be called KLUDGTRAN. 

Principle 2. "Always release preliminary undebugged 
versions of the translators, compilers, generators, assem- 
blers, etc." Why NOT? Let your customers debug the 
things. Why should you spend your programmers' time 
and operate a machine with all that awful overhead? If 
your customers want it badly enough, they'll check it out 
for you. (Unfortunately, the day is gone when you could 
get him to design and implement it, too.) 

Principle 3. "No 'preliminary' or 'field test' version of 
any translator should be compatible with the monitor or 
anv other translator." The savings realized by the elimina- 



tion of coordination and liaison would amaze you. This 
also prevents future coordination and liaison because each 
"field test" version gets too deeply imbedded for anyone 
ever to want the final version anyway. 

Principle 4. "Join and actively support any and all gov- 
ernment sponsored and international magic language gen- 
eration efforts." This lets you know what the opposition is 
thinking. But be careful: contribute only those ideas which 
you know are impossible to implement on the competitors' 
hardware, or will at least make it look bad. Always be 
ready with a claim to have a working version of whatever 
language is the current vogue. 

Principle 5. "Never, NEVer, NEVER write a decent or 
useful training manual for any system." Remember, you 
may be taking the bread out of the mouth of some striving 
young author. 

Principle 6. "If you must supply an assembler, do it 
uder duress." The best ploy to use to get out of this one 
is to tell the customer he never ever needs to know the 
basic language of the machine. All of his problems can 
be solved with the New International Magic Language 
Number 6.5. Well, our version of it anyway. As we all 
know, magic languages are the thing, and you can't sell a 
Kludge without magic. 

We must now turn our attention to software mainte- 
nance; an area too often ignored. 

Tenet 1. "Each program should be on a separate tape 
with its own unique format." This is logical. You wouldn't 
want the corrections for one system to be acceptable to 
another, would you? 

Tenet 2. "Corrections should be distributed at such a 
rate (empirically determined) as to keep the users from 
inundating you with requests for additions and changes 
to the system." It seems best to protect our programmers as 
much as possible from new and different ideas. Besides, 
we've always done business this way. 

Tenet 3. "Distribute new versions of each system as soon 
as the previous one is showing signs of being checked-out." 
This guarantees job security for a very large segment of 
the programmer community known as "System Program- 
mers." 

Tenet 4. "Whenever a new system is proposed or im- 
plemented, refuse to continue maintenance on some other 
(any other) existing system." How far can you make a 
rubber band stretch? We've already provided for keeping 
our programmers busy! 

Tenet 5. "Never let the programmers who implemented 
the system maintain it." It has been found over the years 
that many system programmers acquire a certain attach- 
ment for their own code and refuse to consider sullying 
it with corrections. Thus, the only solution is to have some 
other programmer do the appropriate surgery (preferably 
a brand new one, fresh from the university) in the form 
of absolute binary patches. 

In closing, we should like to point out that we of the 
Kludge Komputer Korporation have managed to keep 
abreast of the competition in software as well as hard- 
ware by having a loyal claque. Which brings us to the last 
Commandment: 



"FORM A USERS GROUP," whence springeth all that 
is worthwhile. Wine and dine them, buy their loyalty and 
in every way possible make sure that your users are satisfied 
and happy. Channel their desires appropriately. Hold meet- 
ings at least twice a year and see that all of the attendees 
get smashed (we at KKK sometimes pick up the tab) and 
go home generally feeling loved, wanted and appreciated 
by all. 

the bitter end 
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